A wide variety of entities use a combination of databases and applications that query those databases to provide users with the ability to view and manipulate information. For example, in an electronic commerce context, a merchant may own a database that stores product information such as stock photographs, product descriptions, and price/availability information. Potential customers are able to view this information by visiting the merchant's website and interacting with assorted web pages generated by the merchant's webserver. In an enterprise context, employees might use a customer relationship management (CRM) application to access and/or update customer information stored on CRM databases.
Allowing end-users to interact with databases can be a convenient and efficient way to assure that those users are presented with up-to-date information. Unfortunately, without adequate protections in place, a nefarious individual may be able to employ techniques such as an SQL injection attack to submit malicious queries to a database, such as ones resulting in the exposure of credit card or other confidential information, or the modification of pricing information.
While a traditional security product such as a log analysis tool might be able to reveal that a database attack has taken place, it is typically unable to provide the identity of the person responsible for the attack. One reason for this is that applications typically authenticate themselves to databases using the same set of credentials irrespective of which end-user is interacting with the application. Additionally, the queries generated by a potentially very large number of simultaneous application users may be multiplexed over a relatively small number of database connections, making forensic attempts to correlate different logs difficult.
One approach to determining who is responsible for specific database activity is to modify the application to record that information. Unfortunately, such an approach is intrusive and inefficient, requiring programmers to modify, test, and maintain a potentially cumbersome feature in every database application. And, in the case where the application is supplied by a third party (e.g., as an off-the-shelf product), modifying the application may not be possible.
Another approach is to record the interactions between users and the application (e.g., using a proxy) and then later attempt to correlate literals appearing in those interactions with literals that appear in SQL statements. Unfortunately, it may not be possible to identify the source of a malicious query when multiple SQL statements contain the same literals (e.g., when multiple users carry out similar activity on the application at the same time) or when there are no literals in the SQL statement.
Therefore, it would be desirable to have a better way to determine the origin of database activity.